Re: Speeding up LIKE with placeholders?
От | Dan Sugalski |
---|---|
Тема | Re: Speeding up LIKE with placeholders? |
Дата | |
Msg-id | a06110408bd67d45b378d@[172.24.10.164] обсуждение исходный текст |
Ответ на | Re: Speeding up LIKE with placeholders? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Speeding up LIKE with placeholders?
|
Список | pgsql-general |
At 5:55 PM -0400 9/10/04, Tom Lane wrote: >Dan Sugalski <dan@sidhe.org> writes: >> Would I regret it if I asked where in the source this lies so I could >> go fix it? > >If it were easy to fix it would have been fixed before now ... Oh, I wasn't expecting it to be an *easy* fix... :) The question is whether it's less work to make the fix in Postgres or in my back-end library code. Worst case I fix it in my code and submit a doc patch, but I'm up for at least investigating the general fix. Since the only difference in this case is that the parameters are pulled out for transport rather than being in band (a properly-escaped string substitution could turn this case from a PQexecParams call into a PQexec call) I was thinking the thing to do would be to either teach the planner to look in the parameter list when it gets handed $xxx variables, or have the back-end do the substitution to the SQL before handing the code to the planner. I'm not sure I like either option (the pre-substitution's got some issues when handed large parameters, while teaching the planner to use a parameter list may require thumping a lot of back-end code) and it may amount to nothing, but I figured it was worth a look, if for no other reason than to find a big mass of code I can safely run screaming from. ;-) -- Dan --------------------------------------it's like this------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk
В списке pgsql-general по дате отправления: